Reducing downtime of computing systems while upgrading is a goal that has been long sought after. Legacy approaches have addressed the problem by deploying techniques to upgrade one or another type of data found in an installation of a computing system, while relying on other techniques to upgrade other types of data found in the same installation. For example, legacy techniques have addressed the task of upgrading a set of software applications that rely on an underlying relational database by shutting down the relational database for a duration, then upgrading the software applications as well as upgrading the relational database structures, and then restarting the relational database.
Strictly as an example of the deficiencies of the aforementioned legacy techniques, an upgraded application might include certain assumptions of an underlying file system (e.g., either format or content), and those assumptions might not become true until a certain time after the software application as well as the file system have both been successfully upgraded. However, in modern environments, the corpus of software application code modules, plus the relational database storage, can comprise a very large storage footprint, which presents a practical constraint to the use of the legacy techniques in that the legacy techniques bring the system down for system-wide upgrades, thus incurring long downtimes during upgrades. Automation is needed. That is, in modern environments, the number of software application code modules to be upgraded, plus the number of relational database storage objects (e.g., tables) to be upgraded becomes large, and the aforementioned technologies fail to address the problem in a manner that can automatically determine an upgrade edition of a relational database object. Therefore, there is a need for an improved approach.